1. Technical Field
The present invention relates to a method of and tool for resource creation in a distributed computing environment.
2. Related Art
A distributed computing environment may typically take the form of lower layers of infrastructure such as operating systems and networks supporting a layer of so-called middleware above which at the highest layer, distributed application programs can be executed. By way of introduction see, for example, “Understanding Networked Applications”, Messerschmitt, Morgan Kaufmann Publishers, 2000. A variety of resources may be located at locations distributed throughout the environment. Typically these resources become visible in the distributed environment by means of middleware provision for making available their existence and capabilities.
Whilst application programs may be aware of the existence and capabilities of such distributed resources, it has often been the case that the heterogeneity of the resources has limited the ability of application programs to capitalise on them.
New resources may be created in this distributed environment. One example of a new resource that may be created is a resource that integrates previously available but heterogenous resources as to provide new functionality. Accordingly, issues associated with the utilisation of heterogenous resources such as information and services have to addressed.
As to the integration of information resources, heterogeneity exists at a number of levels, including for example, the conceptual level and the logical level. Existing information modelling techniques present several shortcomings in terms of their flexibility to model information at both these conceptual and logical levels. Well known examples of such modelling techniques include the relational model, the object-oriented model and a variety of modelling languages such as extensible Markup Language (XML) and other members of the Standard Generalised Markup Language (SGML) family. Each of these examples of well known techniques suffers from the disadvantage that they adopt specific and complex semantics suited to their intended tasks. It is this diversity of modelling semantics that introduces such problems when the need emerges for the integration of different information resources.
As to the integration of services, as indicated, middleware may provide for a degree of integration of distributed service related software components. By way of one example, following the rise of the object-oriented information model, there has been commensurate interest in the possibility of developing distributed objects. Two well known examples of distributed object management systems are the Common Object Request Broker Architecture (CORBA) developed by the Object Management Group (OMG) and the Distributed Component Object Model (DCOM) developed by the Microsoft Corporation.
Such components express their behaviour in interfaces that are defined in an Interface Definition Language (IDL) and are published to client components through Brokers (a client requests an interface from a broker which in turn contacts the interface-provider component). An interface contains the specification of a number of services offered by some component. Hence, an interface can be considered as a package of services or else as a package of behaviour. The implementation of component-based applications is based on the utilisation of such predefined component interfaces. This approach is considered as a static method to integrate behaviour. A dynamic method would enable the construction of dynamic interfaces over runtime which integrate/mix behaviour from a number of components. If such an approach was built utilising the predefined interfaces, it would have created a lot of overhead. This is because every request for a single service would first necessitate request for the whole package of services i.e. the interface the service belongs to. In order to minimise this deficiency/inflexibility there should be reconsideration of the way the components express their behaviour.
One example that has been much addressed of a new resource integrating previously available but heterogenous resources is that of the integration of heteregenous databases. Here, disparate sources of data, created with differing information models and with differing query functionality, are required to be integrated into an apparently single data source, with resultant integrated query functionality. Techniques such as the federation of databases, data warehousing and mediator systems have been deployed.
A so-called Federated-DataBase Management System has been proposed, for which see, for example “Federated Database Systems for Managing Distributed, Heterogenous and Autonomous Databases”, Sheth & Larson, ACM Computing Surveys, Vol 22, Issue 3, September 1990. A model is presented with, for example, five sequential transformations the schema of component databases must undergo in order to participate in the federal system. The databases support different data models such as relational, OO, XML. The final External Schema is expressed in a common, semantically rich, modelling language. Such languages are usually Extended Entity Relationship (EER) or OO that are quite rich and, as was examined above, support very specialised semantic constraints. The transformation must be expressed only in terms of these specialised semantics and therefore the result is complex, non-optimal and inflexible translations.
Another example of a rather different approach to the problem is the use of so-called data warehousing. Data warehousing involves the importation of data from a variety of sources to an intermediary database (the warehouse) of particular design. Client applications can then query this intermediate database. Quite apart from the representational difficulties again arising, significant problems occur in ensuring that the intermediary database reflects the current content of the data sources.
A rather more fruitful approach involves the use of so-called mediator systems. The concept of a so-called mediator as a solution to the problem of integrating heterogenous information was proposed in a paper entitled “Mediators in the architecture of future information systems”, Wiederhold, IEEE Computer 25:3, pp.38–49.
One example of such a mediator system is provided in a paper entitled “The TSIMMIS Approach to Mediation: Data Models and Languages”, Garcia-Molina et al, Journal of International Information Systems 1997.
Having regard to FIG. 1, the TSIMMIS mediator system architecture, as is typical, consists of three layers. A first layer contains heterogenous information sources 100, 102, which might for example each utilise a relational, object oriented or more recently, eXtensible Markup Language (XML) data model. A second layer contains functionality which has effect to transform typically high level queries into a native form which can be used to search the information sources and then transform the native search results back into the high level form. This functionality is provided by so-called wrappers 104, 106, transforming queries and search results into and out of the native form of each information source and the mediators 108, 110, 112 themselves, which act to modify the high level query functionality. A third layer contains the application programs 114 which issue the high level queries.
To these ends, TSIMMIS utilises a component based architecture which provides for:                (i) an information model denoted Object Exchange Model (OEM);        (ii) mediators; specified with a logic-based object-oriented language denoted Mediator Specification Language (MSL) which is designed to operate with the OEM data model and to provide for the necessary functionality in integrating heterogenous information sources;        (iii) wrappers; specified with the Wrapper Specification Language (WSL) and act to transform queries from MSL into the requisite native source form, then transforming the query results into OEM objects as appropriate for return; and        (iv) a query language; MSL is used for the application layer query language, the mediator specification language and the wrapper query language.        
A TSIMMIS query consists of rules. Each such rule consists of a head portion, describing objects made available by the mediator, and a body portion, describing conditions that must be satisfied by the source object. An example of such a query is provided in the paper (Example 3):
“Find the books of which Aho is an author.”                <booktitle X>:                    <library {<book {<title X><author “Aho”>}>}@s1                        
This query thus pertains to a root object library, available at a source s1, which could either be a wrapper or a mediator. This query could itself function as a trivial mediator, in that it exports book titles of books by Aho that are found at source s1.
A template tool is used to generate wrappers. An example is given of such a template (Example 4):                <books X>:-                    <library {X:<book {<title X><author $AU>}>}@s1                        // sprintf(lookup-query, “find author %s”, $AU)//such that the wrapper generated as a result would take the query:        <books B>:-                    <library {<book {<title X><author “Aho”>}>}@s1and generate a native query to the source asking for books in respect of which “Aho” is the author.                        
A limited amount of extension of query functionality is provided for insofar as a notionally unsupported query may be deduced to be logically equivalent to one or more supported queries.
At run time, when a given mediator receives a query request, a Mediator Specification Interpreter aggregates the necessary information from the relevant sources (which might be the wrapper of a native information source or another mediator).
Having regard to the problem of the integration of heteregenous databases therefore, it will be seen that this TSIMMIS mediator solution allows for an expanded query functionality through the construction of new integrating mediators. In this way, respective so-called local views (which is to say the view of a given set of data available with particular query functionality) can be combined to provide ever extensive (local) views. The system so provided in this example cannot however perform any tasks other than the processing of queries to return content.